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Abstract —With the wide adoption of large-scale Internet ser¬ 
vices and big data, the cloud has become the ideal environment to 
satisfy the ever-growing storage demand, thanks to its seemingly 
limitless capacity, high availability and faster access time. In this 
context, data replication has been touted as the ultimate solution 
to improve data availability and reduce access time. However, 
replica placement systems usually need to migrate and create 
a large number of data replicas over time between and within 
data centers, incurring a large overhead in terms of network 
load and availability. In this paper, we propose CRANE, an 
efficient Replica migrAtion scheme for distributed cloud Storage 
systEms. CRANE complements any replica placement algorithm 
by efficiently managing replica creation in geo-distributed infras¬ 
tructures by (1) minimizing the time needed to copy the data to 
the new replica location, (2) avoiding network congestion, and 
(3) ensuring a minimal availability of the data. Our results show 
that, compared to swift (the OpenStack project for managing data 
storage), CRANE is able to minimize up to 30% of the replica 
creation time and 25% of inter-data center network traffic, while 
ensuring the minimum required availability of the data. 

I. Introduction 

With the wide adoption of large-scale Internet services and 
big data, the cloud has become the ultimate resort to cater 
to the ever-growing demand for storage, providing seemingly 
limitless capacity, high availability and faster access time. 
Typically, cloud providers build several large-scale data centers 
in geographically distributed locations. Then, they rely on data 
replication as an effective technique to provide fault-tolerance, 
reduce end-user latency and minimize the amount of data ex¬ 
changed through the network. As a result, replica management 
has become one of the major challenges for cloud providers. 

In recent years, a large body of work has been devoted to 
several challenges related replica management in distributed 
cloud storage systems. A large part of the research efforts were 
mostly dedicated to replica placement problem, considering 
different goals such as minimizing storage costs, improving 
fault-tolerance and access delays Q-0. However, replica 
placement systems may result in a huge number of data 
replicas created or migrated over time between and within data 
centers, incurring large amounts of traffic between data centers. 
This can be the case in different scenarios: for instance, when a 
new data center is added to the cloud provider’s infrastructure, 
when a data center is scaled up or down, when recovering 
from a disaster or simply when achieving performance or 


availability goals, requiring the creation and the relocation 
of a large number of replicas. 

Naturally, several impacts may be expected when such 
large data bulk transfer of replicas is triggered. These impacts 
can be summarized as follows: 

• As copying data consumes resources (e.g., CPU, memory, 
disk I/O) at both the source and the destination machines, 
these nodes will experience more contention for the available 
capacity, which may slow down other tasks running on them. 

• Recent research revealed that traffic exchanged between 
data centers account for up to 45% of the total traffic in 
the backbone network connecting them j^. This ever-growing 
exchange of tremendous amounts of data between data centers 
may overload the network, especially when using the same 
paths or links. This can hurt the overall network performance 
in terms of latency and also packet loss. 

• Replica migration processes are usually distributed and 
asynchronous as is the case for Swift, the OpenStack project 
for managing data storage 0 - That is, when a replica is to 
be relocated or created in a new destination machine, every 
machine in the infrastructure already storing the same replica 
will try to copy the data to the new destination. There is no 
coordination or synchronization between the sending nodes. 
This will not only lead to unneeded redundancy as the same 
data is copied from different sources at the same time, but 
will also further exacerbate the congestion in the data center 
network. 

• Replicas are usually placed in geographically distributed 
locations, so as to increase data availability over time and 
reduce user-perceived latency. When a replica have to be 
created/migrated in a new location, it will not be available 
until all its content is copied from other existing replicas. 
If this process takes too long, it might hurt the overall data 
availability, if the number of available replicas is not sufficient 
to accommodate all user requests. For instance, in order to 
ensure availability. Swift ensures that at least two replicas of 
the data are available at any point in time (according to the 
default configuration 0 )- 

In order to alleviate all the aforementioned problems, 
it is critical to make sure that replicas are created as soon 
as possible in their new locations without inferring network 
congestion or high creation time. This requires to carefully 
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select the source replica from which the data will be copied, 
the paths through which the data will be sent and the order in 
which replicas are created. 


To address these challenges, we start by formulating the 
replica migration/creation problem as an Integer Linear Pro¬ 
gram (ILP). We then propose (CRAN^ an efficient Replica 
migrAtion scheme for distributed cloud Storage systEms. 
CRANE is a novel scheme that manages replica creation in 
geo-distributed infrastructures with the goal of (1) minimizing 
the time needed to copy the data to the new replica location, 
(2) avoiding network congestion, and (3) ensuring a minimal 
availability for each replica. CRANE can be used with any 
existing replica placement algorithm in order to optimize the 
time to create and copy replicas and to minimize resources 
needed to reach the new placement of the replicas. In addition, 
it ensures that at any point in time, data availability is above 
a predefined minimum value. 


The rest of the paper is organized as follows. Section |IJ 
surveys the related work on replica placement and migration 
in the cloud. Section O presents an example illustrating how 
different replica creation and migration strategy can impact 
performance metrics. We then formulate the replica creation 
problem in Section W Our proposed solution is presented in 
Section |V| Einally, we provide in Section |Vj some simulation 
results that assess the performance o f CRA NE and compare it 
to Swift and we conclude in Section [ 


II. Related Work 

In this section, we survey relevant works on replica man¬ 
agement in the cloud. Several efforts have been devoted to 
put forward effective solutions for replica placement problem. 
That is to determine the optimal number and placement of 
data replicas in order to achieve several objectives such that 
minimizing hosting costs, reducing access delay to the data, 
and maximizing data availability 0 - 0 , 0 . Once the replica 
placement algorithm is executed, a new placement of replicas 
is determined in order to achieve the desired objective. Hence, 
some existing replicas should be torn down and some new ones 
should be created across the infrastructure. 

In this work, we do not focus on the replica placement but 
rather on reducing the overhead of migrating from an original 
placement of replicas to the new one, which should take place 
right after the execution of the replica placement algorithm. 
In the last few years, very few proposals have looked at 
this problem but overlooked many important parameters. Eor 
instance, Kari et al. 0 proposed a scheme that tries to find an 
optimal migration schedule for data in order to minimize the 
total migration time. They take into account the heterogeneity 
of storage nodes in terms of the number of simultaneous 
transfers they can handle. However, they have overlooked 
availability requirements as well as network-related constraints 
such as bandwidth limits and propagation delays. Other works 
GD, GD proposed different approximation algorithms to 
solve the problem; however they always aim at minimizing 
migration times without considering the availability of data 

^ CRANE: (Mechanical Engineering) a device for lifting and moving heavy 
objects, typically consisting of a moving boom, beam, or gantry from which 
lifting gear is suspended 


during the migration process. Einally, Swift, the OpenStack 
project for managing data storage Q, implements a data 
replica placement algorithm along a replica migration one. 
As a placement strategy, blocs of data (called hereafter as 
partitions) are replicated and distributed across the distributed 
infrastructure according to the as-unique-as-possible algorithm 
GD which ensure that partition’s replicas are physically stored 
as far as possible from each other in order to ensure high 
availability. In terms of replica creation and migration. Swift 
simply do migrates replicas between data centers without 
considering the network available capacity. However, it ensures 
a high availability of the data by allowing only one migration 
per partition each time interval (usually, one hour) so that only 
one replica can be missing at a particular point of time. Of 
course, the 1-hour waiting time for triggering migrations will 
significantly increase the total time needed to reach the new 
optimal placement of replicas. 

Different from previous work, CRANE takes into account 
not only the network available capacity but also data avail¬ 
ability during the creation of the new replicas. Eurthermore, 
it capitalizes on the existence of multiple replica across the 
network in order to carefully select the source of the data and 
the transmission path in order to avoid network congestion and 
minimize data migration time. 


III. Motivating Example 

To introduce our proposed replica placement solution, a 
motivating example is described in this section. Let’s consider 
a cloud system composed of two data centers that span multiple 
geographic regions. The data centers have different storage 
capacities and are interconnected by different capacity links. 
This cloud deployment uses Swift as a distributed solution for 
managing storage functionalities. Consider a scenario where 4 
partitions A, B, C and D with sizes 300 GB, 100 GB, 500 
GB and 200 GB, respectively, are configured. Each partition 
is replicated 4 tim es and the replicas are stored across data 
centers. Eig. 1 1(a)[ illustrates the initial mapping of the replicas 
on the data centers. 


When a new data center is added, partitions are relocated 
according to the as-unique-as-possible algorithm, respecting 
the capacity of the disks on servers in the data centers. To reach 
the new configuration, bulk volumes of replications will be 
migrating. Starting from the time where we decide to relocate 
the replications, all the Swift components will operate accord¬ 
ing to the new mapping of the replications, directing client 
requests to non-existent replicas, resulting in unavailability. 
Swift requires a majority of replicas responding to consider 
a retrieval operation successful. Thus, to avoid unavailability 
of the replicas. Swift specifies in its configuration the number 
of hours to restrict moving a partition more than once. In our 
scenarios, we assume this parameter to be one hour. Thus, 
Swift will not move two replicas of the same partition at 
the same time, but wait an hour before moving the second 
replica. It is important to note that the second migration is 
not triggered automatically. Instead, the cloud administrator 
should run a command to recompute the location of the 
replications, and then migration starts. Also, in this scenario, 
the minimum tolerated avai labilit y of replicas of each partition 


is assumed to be -. Eig. 


1(b) 


shows the optimal locations 
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Fig. 1. Initial and final replication mapping 


of the different replications according to the disk capacities 
and the as-unique-as-possible algorithm. The depicted final 
configuration is reached after several calculations of locations 
and migrations. 


Migration of replications in Swift is a peer-to-peer asyn¬ 
chronous process. Each storage server will sequentially run 
through its replications and compare them to the ones on 
the servers assigned to hold a copy of this replication. The 
migration process uses a push model, so each time a replication 
needs to be present in one server and it’s not, this replication 
will be copied from the local server to the remote one. And 
if a server holds a copy of one replication that shouldn’t be 
there it should delete it. Fig. 2(a)[ represents an example of the 
replication migration sequence. In this figure, the bottom line 
represents time in minutes and the replication identifiers of 
each partition are represented on the vertical line. For instance 
each storage server starts sequentially copying the replicas 
to the servers that should hold a copy of them and are not. 
However, the following problems arise: 


Availability: The number of hours to restrict moving a 
replica of the same partition is a parameter defined by the 
storage provider. In this scenario it’s set to one hour. But 
migration of replications might take more than one hour. This 
may have a bad impact on the minimum tolerated availability 
of replicas per partition. In the depicted scenario, copying 
replica C3 from DCl to create C4 on DCS have taken more 
than one hour, and the new computation of location of replicas 
dictated that D3 should be migrated to DCS. So, in the second 
migration sequence, we have both C4 and C3 that are not 
available on DCS during the five first minutes. This violates 
the minimum required replicas available per partition. 


Redundancy: There is a redundancy on the creation of the 
replica D4 on DCS. Infact, replication D3 and D4 are copied 
from DCl and DC2, respectively. This redundancy implies 
needless bandwidth consumption, which increases replication 
migration time. Moreover, the copying of B2 from DC2 to 


X y:DCn ^ Wz:DCm 

I I Creating replication Wz in DCm from 

replication Xy in DCn 

XZv:DCn 

I Deleting Replication Zy from DCn 

S Size of replicas that are migrating 
A Minimum replicas availability per partition 
T Time for migration 



(a) Example of Swift replication migration sequence 



(b) Novel replication migration sequence 


Fig. 2. Replication migration sequences 


DCS is delayed. Indeed, all the storage servers were copying 
the first replica in their list, that is, B2 started to be copied 
only when the server was finished copying D4. 

Migration time: Each storage server on Swift starts copying 
the replicas of the partitions that need to be migrated without 
any calculation on the delays that this task would take. 
Therefore, one storage server could end up copying a replica, 
even though, there exists another server with a replica of the 
same partition, which could have performed the replication 
faster. For example, in order to create D4 in DCS, copying 
D3 from DCl takes less time than copying D4 from DC2. 
This could be due to the difference on the available bandwidth 
on the links and the propagation delays between data centers. 
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Moreover copying a replica within the same data center will 
lead to better migration time. 

Idle time: We notice there is always an idle time between 
two sequences of migration. 


To avoid the aforementioned drawbacks, we prop ose an 
enhanced migration solution illustrated in Fig. 2(b) Note, 
avoiding the redundancy of copying replicas increases avail¬ 
able bandwidth and thus decreases migration time. Also, smart 
selection of copying source further reduces the migration time 
significantly. In fact, creating replicas from within the same 
data center or from a distant data center with links having 
better propagation delay and less bandwidth consumption will 
lead to a faster migration time. Furthermore, the minimum 
replica availability tolerated per partition should be maintained. 
Finally, automating the recalculation of the location after each 
sequence of migration leads to avoiding idle time and faster 
convergence to the final mapping of replicas in data centers. 


TABLE II. Problem variables 


Variable 

Definition 

X 

|<S'| X \P\ X \S\ X T matrix representing migration sequence, where 
f 1, if Si is migrating replica of pj to s^ at time t 
Xz,j,k,t — Otherwise 

Y 

1 (S' 1 X \P\ X \S\ matrix representing a need for partition migration, 

, _ f 1, if Si is the provider of replica of pj to s^ 

w ere — < 1 ^ 0, otherwise 

Z 

1 (S' 1 X \P\ X T matrix representing replica placement, where 
_ j 1, if Si has replica of pj at time t 
otherwise 

L 

\E\ X T matrix representing load le,t on edge e at time t, where 

le,t Pe 

R 

|(S| X \P\ X |(S| X T matrix, where rij^k,t represents the 
bandwidth allocated for migrating replica of pj from Si ro s^ at time t 

D 

1 (S1 X \P\ matrix representing the replicas that are to be deleted at 
time T, where 

^ r 1, if replica of pj will be deleted fromsi 

~ 1 0, otherwise 

V 

\S\ X \S\ X T matrix, where Vi,fc,t represents the capacity of the 
path between Si to s^ at time t 

W 

A vector of size T, where 

f 1, if migration is in progress at time t 
~ 0, otherwise 


IV. The Replica Migration Problem 
A. Problem Statement 

Given a network represented by a graph G = (S', E), 
where S = {si, 52 ,..., 5 /^,..., S| 5 |} is the set of all 
servers across data centers. We assume that data centers are 
connected through a backbone network. The backbone’s links 
are represented by a set of edges E. Each edge e e E 
is characterized by a bandwidth capacity Let P = 

denote the set of partitions, replicas of 
which are stored across the servers where \pj\ is the size of 
replica of partition pj . We define a configuration as a particular 
placement of the replicas of partitions within servers. Given 
an initial and a final configuration, denoted respectively by 
and our goal is to find the optimal sequence of replica 
migrations that minimizes the migration time from to 
while meeting the minimum partition availability threshold A 
and abiding by edge bandwidth capacities. We model this 
as an Integer Linear Programming (ILP) problem. Tables I 
and II show respectively the inputs of the ILP and its variables. 


TABLE 1. Problem inputs 


Input 

Definition 

(S 

Set of servers across data centers, where S = 

|si, S2, Si, ..., Sfc, ..., Sj^i 1 

E 

Set of edges connecting servers in S 

Be 

Bandwidth capacity \/e E E 

P 

Set of partitions, where P = ^pi,P 2 , ■■■,P\p\^ and \pj\ is 

the size of partition pj 


|(S'| X \P\ matrix representing an initial configuration, where j = 
r 1, if replica of pj is stored on Si 

1 0, otherwise 


\S\ X \P\ matrix representing a final configuration, where cf ^ = 

j 1, if replica of pj is stored on Si 

1 0, otherwise 

T 

Worst-case migration time 

G 

1 (S' 1 X 1 (S1 X 1 1 matrix representing edges used in a path, where 

( 1, if edge e is used in shortest 
gi,k,e = s path between Si and Sk 

( 0, otherwise 

/3 

A big constant 


B. Constraints 

Given the initial and final configurations, any discrepancy 
in the configurations necessitates either the migration or the 
deletion of the partition replicas. Consider that the migration or 
deletion of the replica is identified by variables Vij^k 
respectively. Then, if a server Sk has replica of partition pj 
in the initial and final configuration and no action is required, 
then there should be no migration of replica of partition pj 
from any server Si to Sk, that is, = 0, and there 

should be no deletion of replica of partition pj from server 
Sk, that is, dkj = 0, as in 0- However, if the replica of 
partition pj is present on server 5/^ in the initial configuration 
and not in the final configuration, then the partition should be 
eventually deleted, hence, dkj is set to 1, with constraint 0- 
Most importantly, in constraint 0 we capture the need for a 
replica migration, if the server Sk does not have the replica 
of partition pj in the initial configuration. In this case, there 
should be some server Si that delivers the replica of partition 
Pj to server Sk, therefore yij^k = 1- 

isi 

+ E ~ = E VI < A: < |5|, 1 < j < |P| 

( 1 ) 

dk,j > clj - clj VI < fc < |5|, 1 < j < |P| (2) 

|S| 

Eyid,k > Ckj - 4,j VI < fc < |5|, 1 < j < |P| (3) 

i=l 

Before we can initiate the migration, we have to identify the 
servers Si that hold the replica of partition pj at time f, in 
variable Zij^t in constraint 0. To begin the migration, only 
those servers Si can participate in the replica migration that 
hold a replica of partition pj in the initial configuration. 

clj < P-Zi,j,t VI < i < |5|, 1 < i < |P|, 1 < f < T (4) 

The variable Zkj^t that indicates potential sources of replicas 
that indicates potential sources of replicas is updated in each 
time instance t, as servers Sk may begin to hold a copy of 
the replica of partition pj, due to migration in earlier time 
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instances, as in constraints and A server holds a copy 
of the replica when the sum of all the bandwidth allocated, 
to the migration of that replica of partition pj from 
source Sj to destination Sk, in previous time instances Vf' < f, 
equals the size of the partition pj. Then, in following time 
instances, server Sk could potentially participate in the replica 
migration. |^| ^ 

H H < /3 • (1 - Zk,j,t+l) 

k=l,i^k t'=l 

{^^<{< \S\,l<j < \P\,l<t<T-l (5) 

~ 12 ^ 1 - ^k,j,t+l 

k=l,ij^k t'=l 

VI < i < |5'|, 1 < j < |P|, 1 < t < T - 1 (6) 

The bandwidth allocated for migration of replica of partition 
Pj at time t from source Si to destination server in variable 
is dependent on the capacity of the shortest path from 
Si to Sk, in variable Vi^k,t, or the remaining size of the partition 
replica to be migrated in constraint 

1*51 t-i 

ri,j,k,t = argmin{\pj\ - rjj^kg',Vi,k,t} 

k=l,i^k t' = l 

ij^k< \S\,l<j < \P\,l<t<T (7) 


The capacity of the shortest path between Si and Sk is inferred 
from the load on the edges traversed in the path. The edge 
with the least capacity, bounds the capacity of the path from 
above. The available path capacity at time t is in constraint ([8]). 
The edges can be traversed by multiple paths, that is, multiple 
paths between different source destination pairs can share 
common edges. Therefore, the load on an edge, not exceeding 
edge capacity, is conjured as the sum of all partition replicas 
migrating in the network across all source and destination 
servers at time t, on edge e in the shortest path between Si 
and s/c, by constraints 0- 

Vi,k,t = argmin{{Be - le,t) ■ 9i,k,e 1 < e < |£;| } 

|S| |p| |s| i^k< \S\,l<t<T (8) 

le,t =121212 9i,k,e-riJ,k,t VI < 6 < \E\,1 <t <T 

i=l j=l k=l 

(9) 


Once the model has been initialized with potential providers, 
need for migration and the bandwidth allocated for the mi¬ 
gration of partition replicas, we can initiate migration by 
associating the replica of partition migration indicator variable 
with need for migration of replica of partitio n pj 
from Si to Sk, in variable yij,k, in constraints (p^ and (pT). 
Consequentially, from ( p^ and ( pT] ), we ensure omy sequential 
migration of replica of partition, since concurrency is set to 1. 
Furthermore, in constraint ( p^ , we bind the source server Si, 
such that, only those servers that hold complete replica of 
partition pj can initiate migration. 


T 

^ V ^'i'd,k,t ^ P'UiJ^k 
t=l 

T 

^ ^ ^i,j,k,t ^ yi,j,k 
t=l 


yi<i,k, i^k< |5'|,1< j< \P\ 

( 10 ) 

VI < i, /c, i ^ k < |5'|, 1 < j < |P| 

( 11 ) 


1*51 

12 Xij,k,t < VI < i < |5|, 1 < j < \P\,l<t<T 

k=l 

(12) 

To ensure continuous sequential migration of replica of parti¬ 
tion Pj , from same source server Si to same destination server 
Sk for next time instance t+1, we set the indicator of migration 
is progress, in variable Xij^k,t+i^ to 1, until the entire replica of 
the partition has been migrated. This is depicted in constraints 
( p^ and ^ 

ii-Xij,k,t+i > \pj\ -12^ij,k,t' 

t'=i 

\/l<i,k, i^k< 1^1,1 < i < |P|, 1 < t < T - 1 (13) 

^i,j,k,t+l < \Pj\ — ^i.i.k.t' 

t'=l 

\/l<i,k, i^k< |5'|, 1 < j < |P|, 1 < t < T - 1 (14) 

During the migration process the servers must maintain the 
minimum availability threshold for each partition with con¬ 
straint 

l-si 

^ yi<j<\P\,l<t<T (15) 

The total migration time is extended to include all migrations 
in progress in constraint and stopping the migration 
process in constraint 0- 

Wl<i,k, i^k< l^l, 1 < j < |P|, 1 < t < T (16) 
Wt > ict+i VI < t < T — 1 (17) 


C. Objective 


minimize 



(18) 


We minimize the total migration time in (18). As the optimiza¬ 
tion minimizes migration times, it will select source servers 
for replica migration that reduce migration time, such that 
it selects source-destination pairs that have minimum over¬ 
lapping edges in the shortest path, while ensuring sequential 
migrations, meeting minimum partition availability threshold 
and abiding by edge bandwidth capacities. 


V. Solution Design 

In this section we will describe CRANE, our heuristic 
solution for the replicas migration problem. Given an initial 
and a target replicas mapping in data centers, the goal of this 
algorithm is to find the best sources for copying the replicas 
and the best sequence to send them so as to minimize the 
total replica creation/migration time. To this end, the following 
sights can guide the replication replica creation/migration 
sequence : (1) avoid redundancy, (2) select the source of data 
and paths having more available bandwidth, and (3) avoid idle 
time between sequences. 

Our heuristic solution is described in Algorithm 1. Given an 
initial and target placement configurations (i.e., and C^), 
Algorithm 1 returns a set Q of sequences Qi for migration. 
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Each sequence contains an ordered set of replicas to be 
migrated/created such that the required minimum availability 
per partition is satisfied. After each sequence of migrations 
Qi, cloud storage components will be updated with the new 
placement, so that data user requests can be redirected to the 
right partition locations. The final replica placement is reached 
once all the sequences i < n are executed. 

Initially, P contains the set of partitions that need to be 
created/migrated. This set can be computed based on the initial 
and the final partition locations (i.e., and C^). We then 
initialize Q that should contain the sequence of replicas to be 
migrated. In line 3, we initialize a variable i that denotes the 
number of the sequence. The core of the algorithm aims to 
iteratively add a partition replica on ordered sequence Qi. We 
create a new sequence whenever it is not possible anymore to 
add a replica creation/migration to the current sequence (not 
possible because otherwise we do not satisfy the minimum 
replica availability per partition). 

The variable available is true if there still some replica 
that can be added to the sequence Qi. As long as available 
is true, we iterate over all partitions in P and we choose 
the replica from the set of replicas Rp of each partition 
p that minimizes the migration time. For that we use the 
variable Tq-^R^^min that denotes the minimal migration time 
of the sequence Qi when a replica of partition p is included. 
We compare this variable to TQur, the migration time of the 
sequence Qi if replica r is included (line 15). This allows us to 
select the best replica of the partition p. From the selected 
replicas, we need to select the one that minimizes migration 
time (denoted by r^). To do so, we use the variable Tq-^min 
which denotes the minimal migration time after adding a new 
replica to the sequence Qi (line 9). We then choose from all 
previously selected replicas the one that minimizes migration 
time after adding a new replica (line 20 to 23). The chosen 
replica is then added to Qi (line 26). The partition p whose 
replica was selected is then removed from the set P. 

To detect that we cannot add any more replica to the 
sequence Qi, we iterate over all partition until the variable 
available becomes True. At that time, we add the sequence 
to Q, and start a new one as long as we still have partitions 
in P to migrate/create. 

VI. Performance Evaluation 

In this section, we compare the performance of Swift using 
CRANE for replica migration with the traditional Swift, with 
respect to migration time, amount of transferred data and 
partition availability. 

A. Deployment scenarios 

Our evaluation environment consists of five data centers, 
each consisting of five storage servers. We use the NSFNet 
topology as a backbone network interconnecting the data 
centers (H). We use the standard Swift configuration stipu¬ 
lating that for each data partition, three replicas have to be 
created and placed according as-unique-as possible algorithm. 
Furthermore, swifts assumes that if 2 out of the 3 replicas 
are available, the data is assumed to be available (i.e., all user 


Algorithm 1 CRANE 

require: Initial configuration . 
require: Final configuration 
output: Sequence for migration 

1: P ^ partitions to be migrated 
2: Q ^ { 0 } 

3: i i — 0 

4: while P / { 0 } do 

5: Qi ^ { 0 } 

6: available ^ True 

7: while available == True do 

8: available ^ False 

10: for each p e P do 

11 : if p can be included in Qi then 

12: available ^ True 

13: CO 

14: for each r e Rp do 

15: if Tq^pr <c Tq^^R^^jYiiji then 

1^' ^Qi,Rp,min — ^Qi,r 

17: ri) = r 

18: end if 

19: end for 

20: if ’^Qi,min then 

21- Tq^^jYiiji = T(Qi,i7p,min 

22 : rs = rb 

23: end if 

24: end if 

25: end for 

26: Qi Qi 

27: P = P — {partition p of replica rs} 

28: end while 

29: Q = QUQi 

30: i i — i \ 

31: end while 
32: return Q 


requests can be accommodated). Hence, the minimum required 
availability per partition is set to 2/3. 

In our simulations, we consider four scenarios as depicted 
in Table Each having different number of partitions placed 
across the data center with different partition sizes. In the 
beginning of each experiment, we consider only 4 data centers. 
After that, a new data center is connected to the infrastructure, 
which triggers the placement algorithm in order to re-optimize 
the location of replicas. We then use whether swift combined 
with CRANE or the traditional swift to migrate or create new 
replicas. For instance, in scenario 1, we originally have 512 
partitions (i.e., 1536 replicas) distributed across the infrastruc¬ 
ture. When the fifth data center is added, 656 replicas should 
be migrated or created across the fifth data centers (Table [In|. 


B. Results 

For each scenario, depicted in Table we compare 
(Swift -I- CRANE) with traditional Swift with respect to the 
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Fig. 3. Performance comparison between CRANE and traditional Swift. 


TABLE III. Deployment scenarios 


Scenario 

Total number of 
partitions 

Number of repli¬ 
cas to migrate 

Range of replicas 
size (Gb) 

1 

512 

656 

50-100 

2 

1024 

1316 

20-50 

3 

2048 

2632 

20-50 

4 

4094 

5264 

10-20 


following performance metrics: (1) the total migration time, 
(2) the amount of inter-data centers exchanged data, and (3) 
the availability of replicas per partition. 


Figure 3(a) shows the total migration time for the 
considered scenarios. As we can see, in all scenarios, 
(CRANE -I- Swift) outperforms the Swift algorithm by a good 
margin. For scenario 1, the swift algorithm takes 315 min to 
create all the replicas compared to 217 min for CRANE, which 
constitutes around 30% of improvement. For scenario 2, the 
replicas are migrated within 300 min with swift and 200 min 
with CRANE, which constitutes around 30% improvement. For 
scenarios 3 and 4, CRANE achieves 25% improvement. These 
results are as expected, because CRANE always chooses to 
copy the replica incurring the minimal transmission time. 


data while avoiding redundant copy of replicas and eliminating 
idle time. 


VII. Conclusion 

Data replication has been widely adopted to improve 
data availability and to reduce access time. However, replica 
placement systems usually need to migrate and create a large 
number of replicas between and within data centers, incurring a 
large overhead in terms of network load and availability. In this 
paper, we proposed CRANE, an efficient Replica migrAtion 
scheme for distributed cloud Storage systEms. CRANE com¬ 
plements replica placement algorithms by efficiently managing 
replica creation by minimizing the time needed to copy data 
to the new replica location while avoiding network congestion 
and ensuring the required availability of the data. In order 
to evaluate the performance of CRANE, we compare it to 
the standard swift, the OpenStack project for managing data 
storage. Simulations show that CRANE is able to to reduce up 
to 30% of the replica creation time and 25% of inter-data center 
network traffic and provide better data availability during the 
process of replica migration. 


The amount of transferred data inter-data centers is re¬ 
ported in figure |3(b)[ For the 4 different scenarios the CRANE 
algorithm have less amount of data transferred. The improve¬ 
ment is around 25%. This improvement is explained by the 
avoidance of redundant copy of the replicas of the same 
partition. This have also induced the improvement in migration 
time showed in figure |3(a) 


Einally, figure |3(c) shows the Inverse Cumulative Distri¬ 
bution Eunction (ICDE) of the availability. Eor a given avail¬ 
ability, it provides the probability of having that availability 
or higher. The required minimum availability per partition 
(2/3 = 0.66) is always met for both algorithms as we can see 
that the probability of having an availability higher than 66% 
is 1. However, the probability of having a high availability is 
always higher for the CRANE algorithm than the traditional 
Swift. Eor instance, the probability of having an availability 
higher than 80% is 0.60 for Swift whereas it is around 0.76 
for CRANE. When comparing the two curves, we can see that, 
on average, CRANE improves availability by up to 10%. 


It is clear that CRANE performs significantly better than 
the basic Swift algorithm as it carefully selects the replica from 
which the data should be copied, the paths used to transmit that 
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